\section{Introduction and Background}

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols for secure communication that are in widespread use on the Internet. Although these protocols have minor differences, we consider them the same for the purposes of this paper and refer to them as SSL. Like other cryptographic protocols, SSL relies on the strength of randomly generated values to ensure uniqueness of keys in order to prevent eavesdropping, session hijacking, and other attacks. Additionally, TCP/IP session security relies on random TCP session numbers to prevent connection hijacking and denial of service attacks \cite{joncheray1995simple}. \\

Previous work on examining substandard generation of random values most notably includes the work of Nadia Heninger \emph{et al.} on weak RSA keys found via whole address space scans over SSH servers \cite{heninger2012mining}. Through a new all-pairs GCD algorithm they were able to recover private keys for 0.50\% of SSL hosts and 0.03\% of SSH hosts and find 0.75\% of keys are repeats over different servers. In a related study by Lenstra \emph{et al.}, 5.5 million PGP keys were collected and 0.2\% of RSA moduli collected were found to offer no security \cite{lenstra2012ron}. \\

In this paper we analyse captured SSL traffic for potential sources of insecurity. While SSL is considered to be a sufficiently strong and practical protocol in theory, there is a large gap between protocol design and implementation in both hardware and software. It is currently unknown which commonly used implementations suffer from flaws and on this we aim to provide insight. As described in the following section, the protocol relies on values generated at both the client and server ends, leading to the necessity to capture and evaluate numerous record types. Possible kinds of insecurity investigated including repeated random values across different clients/servers and low exponent RSA keys. \\

\paragraph{SSL Protocol.}

While the full SSL protocol is outlined in detail in the RFC\cite{rfc6101}, here we go into a few of the key details necessary to understand the handshake protocol. SSL data is encapsulated in a record of one of three types; ‘Handshake’, ‘Alert’, or ‘Data’. Our investigated focuses only on the ‘Handshake’ record, wherein random values are exchanged. The record header includes the SSL version and length, and record type. The record type field encodes what step in the handshake is within the packet. Multiple SSL records can be sent within a single packet, and allowable flows are defined in the RFC. See Table \ref{table:handshake} for a list of the handshake types.

\begin{table}[h]
\centering
\begin{tabular}{lrc}
SSL3\_MT\_HELLO\_REQUEST         &   0 &  (x'00')\\
SSL3\_MT\_CLIENT\_HELLO          &   1 &  (x'01')\\
SSL3\_MT\_SERVER\_HELLO          &   2 &  (x'02')\\
SSL3\_MT\_CERTIFICATE           &  11 &  (x'0B')\\
SSL3\_MT\_SERVER\_KEY\_EXCHANGE   &  12 &  (x'0C')\\
SSL3\_MT\_CERTIFICATE\_REQUEST   &  13 &  (x'0D')\\
SSL3\_MT\_SERVER\_DONE           &  14 &  (x'0E')\\
SSL3\_MT\_CERTIFICATE\_VERIFY    &  15 &  (x'0F')\\
SSL3\_MT\_CLIENT\_KEY\_EXCHANGE   &  16 &  (x'10')\\
SSL3\_MT\_FINISHED              &  20 &  (x'14')\\
\end{tabular}
\label{table:handshake}
\caption{SSL Handshake type values}
\end{table}

The standard RSA handshake flow is described below (note: we excluded some values unimportant to our analysis). See Figure \ref{fig:ssl} for a diagram of a typical SSL message flow. \\

Client sends 'CLIENT\_HELLO' with a list of supported ciphers, the session ID (normally initialized to 0) and importantly, the client random. The client random is 4 bytes of a datetime stamp prepended to 28 bytes of randomness. This is one of two values used to initialize the Premaster Secret, a value from which all the session keys are derived. \\

Server responds with 'SERVER\_HELLO'  that includes the cipher to be used for the session, the session ID and the server random, a value generated the same way as the client random. 
The server also sends 'CERTIFICATE' that includes the server's certificate, and can also include a chain up to the root certificate authority if need be. Following these two records, the server includes 'SERVER\_DONE'. These three records may be included in a single packet. \\

The client then verifies the server’s certificate and if it validates correctly performs the following steps. It generates the premaster secret (PMS) by concatenating the two bytes of the protocol version with another 46 random bytes. It encrypts the PMS with the servers public key and sends the result to the server in a 'CLIENT\_KEY\_EXCHANGE' message. The client then sends 'CHANGE\_CIPHER\_SPEC' indicating that all future communications from the client will be encrypted. The client also sends 'FINISHED' to indicate that it has completed the handshake. The FINISHED message includes a digest of the entire handshake to allow verification of all the steps. \\ 

The server then responds with a matching 'CHANGE\_CIPHER\_SPEC' and 'FINISHED' and regular SSL packet exchanges commence. The server and client now both have a copy of the PMS and can thus compute the master secret. The master secret is then used with a key expansion function to generate individual keys needed for signing and sending data on the channel, and are used as expected to secure the session. \\

Random values are commonly generated by the OSRNG but this can vary from implementation to implementation. This is a potential source of issues as misuse of a PRNG, insufficiently seeding it or doing so improperly before generating random values can result in duplicate values being produced.

\begin{figure}[h]
\centering
\includegraphics[width=10cm]{../images/ssl.jpg}
\label{fig:ssl}
\caption{SSL handshake}
\end{figure}
